An Internet Protocol (Internet Protocol, “IP” for short) multimedia subsystem (IP Multimedia Subsystem, “IMS” for short) is a main landmark stage for a communication core network to implement all-IP evolution. Currently, with convergence between a fixed network and a mobile network of each carrier and combination between an information technology (Information Technology, “IT” for short) and a communication technology (Communication Technology, “CT” for short), the IMS has stepped into a period for implementation and commercial use, and each domestic carrier has also begun a test of the IMS and its intelligent services.
As a communications network evolves towards the IP, a requirement for developing a communications service lowers and subsequently, a service management problem needs to be faced. In the IMS architecture, initial filter criteria (Initial Filter Criteria, “IFC” for short) may be used to control the triggering of each service, thereby implementing separation between a service and its control. In addition, the IFC can be compiled into a very flexible extensible markup language (Extensible Markup Language, “XML” for short) script to determine the triggering of each service. However, this still results in a service conflict. Therefore, a 3rd Generation Partnership Project puts forward a concept of a service broker (Service Broker, “SB” for short) to resolve the problem of the service conflict.
As a next generation broadband network develops towards the IP, various services, including a voice service, run on an IP network, and therefore a problem of quality of service (Quality of Service, “QoS for short) arises in providing a service. A huge difference exists between requirements of users, and quality requirements on a same service are also different. That is, a user may sign different service level agreements (Service Level Agreement, “SLA” for short) according to an actual requirement of the user and selects a proper charging mode. Therefore, the QoS becomes an essential element involved in each charging layer. When the QoS changes, it is required that a corresponding charging mode can be selected promptly, thereby implementing a real dynamic and accurate charging. In addition, to keep a leading position in a value chain and avoid being channelized, a carrier may identify a service flow and content through content perception and an in-depth packet detection technology, so that various services on a network can be perceived and a corresponding charging mode is provided, thereby meeting different requirements of different service providers.
To implement threshold control, QoS control, and charging control at a service data flow level, the 3GPP Release 7 formulates a specification related to a structure of a policy and charging control (Policy and Charging Control, “PCC” for short) system based on flow based charging (Flow Based Charging, “FBC” for short) in the Release 6. The PCC system combines a policy control function (that is, a service based local policy (Service Based Local Policy, “SBLP” for short)) and a flow based charging function (that is, FBC) which are in the R6 version and integrates a function of a related interface.
On the PCC system, an application function apparatus (Application Function, “AF” for short) and a policy and charging rules function apparatus (Policy and Charging Rules Function, “PCRF” for short) connect with each other through an Rx interface to control the QoS. Therefore, the AF focuses too much on details that are not related to a function. QoS requirements among different AFs may be different. That is, some may be associated with others, and some may even conflict with others. Therefore, how to effectively control and manage the QoS is a technical problem that needs to be currently resolved.